< wiki theories


After working with seedwiki for 6 years I am left with multiple theories about wikis.  See also development theory:

A theory of wikis takes its place in a theory of work.

The idea of work belongs to the world of local fabrication, rather than the world of manufacturing. In manufacturing terms you get a job, in a workshop, or on a workday a group of people (for work is always social, even if only one person is present) work together, even if they are doing different things. In manufacturing terms you always do your job alone, since the job is designed to be filled by "any" body and defined in a way that makes its functions real, but diminishes the reality or physical persence of the person doing it. Thus you can ship a "job" offshore.

This difference between modes that depend on and enhance the personal presence and modes that define themselves of functionality and erase the personal persence can also be seen in the design of computer "applications". A computer application is precisely designed to that "any" body can use it, and its use reduces the person using it to a "body", a place holder, a replaceable operator. ( also note the soldiers description of what he is doing, "just doing a job")

In a local work place there is the constant opening of communication among the workers... see FAB's description about how people help each other learn how to use the tools and machines necessary to do their work. On a job, on the other hand, people tend to work by themselves and see communication as a separate function (that therefore competes with the functions they have been assigned as their "job"), thus the bosses complain that they have a hard time ever getting people to talk to each other or ask each other questions. This isolation of the job leads to counter measures (designed as "applications") to attept to "capture" or "share" the "knowledge" of the people who do the jobs.

It is important to realize that these 2 different approaches do not exclude each other. As Deluze and Guattari point out such "striated" and "fluid" states co-exist with each other and are constantly turning into each other. To actually get something done people defined by their jobs must move into "work" mode, and as people work they take on roles and responsibilities that they then use to define what they are doing as "jobs".

I would like to say that a wiki is a "work", in the sense the word is used in "work of art". The french word "ouvre" is closer to the sense I want, but probably not accessible enough. As a compromise I'm going to try saying:
A wiki is a publication, and its pages are publications, whether they contain words, images, video or music. My primary conceptual tools for dealing with wikis as publiscations comes from the body of critical theory built up around other texts in literature can be applied to it. Giles Deleuze and Felix Guatarri's ideas about the interplay between mobile and structured spaces, their ideas about making things multiple, Roland Barthe's ideas about writeable text and Jean-Francois Lyotard's ideas about texts as competitive games and about texts as inhuman mechanisms all seem to be very useful in thinking about wikis.

You can also think of wikis as a work-shop or work-space. Wikis are flat, non-hierarchical collections of pages (or other kinds of content). The discussion of the difference between working in abstract, hierarchial spaces and flat spaces in ?'s "about face" applies to this approach to wikis. wiki's like spreadsheets and email are "monocline hierarchies", that is, they are "piles of stuff", organized the way many people organize their desks (or their work-shops). The flat space of a wiki can be used to "flatten out" complex, hierarchically organized information and present it to people in a way that makes it easier to grasp and put to use. Because data-driven widgets can be embedded in wiki's the information in their pages can also be converted to abstract, hierarchially stored data. This is a good example of Deleuze's idea that "smooth" and "striated" spaces do not displace each other but are both always present on opposites sides of a "border" where the two difference kinds of organization change back and forth into each other.

What happens in the wiki work-shop is local fabrication, an activity whose methods, means and products are radically simpler than the industrial model of manufacturing we are accustomed to. The ideas in Neil Gershenfeld's book "Fab" give us a model in the physical world that we can apply to what a goup of people do on-line in a wiki.

A wiki can also be seen as a machine, a tool, an apparatus. Like all tools it only becomes a tool when it is grasped. The way it is grasped by the community that uses it is not the same thing as the way it is made. Thinking about the wiki as a tool, or a whole set of tools (a workshop) can be advanced by looking at the ideas around local fabrication developed by ? at MIT. In particular his description of the high degree of innovation encouraged by local fabrication, the radical simplicity of things made for local use , the self-generating help systems that arise around local making  and the speed and agility of local fabrication? shed a lot of light on what happens in wikis. However, I think the most important idea from his book is the whole work-shop with its individual tools as an apparatus that can be used to reshape and remake itself. This ability to locally make and use tools means that the workshop is a sort of Turing-machine and can reshape itself to do any sort of work that is required.

The wiki can be thought about as an artifact which bears traces of its making, or as an application, a tool structured to be used in certain ways. But looking at many groups making wikis over a long time has convinced me that the kind of artifact a wiki is and the way it is structured as an application are not inherent in the wiki, they are an accidental result of the particular use made of that wiki. There are no "typical" wiki users and not "typical" things you can do with a wiki. This means the the traditional strategy of structuring computer programs as "applications" (cf Naked Objects) meant to facilitate certain types of users do certain types of things does not work well for building wiki environments. In a wiki environment  there is the possibility for a new category of participant to appear in a space between the developer and the user, we call these people "contributors". The wiki allows them to innovate, design and create tools for themselves and their groups at the level of writing, rather than at the level of programming. There is a long history of trying to find a way to allow "users' to somehow become "programmers", dating back to the origins of COBAL, and many of these efforts (like the development of the spreadsheet) have been very successful.

A wiki is best thought of as a tool rather than as an application. The theories that can be found on nakedobjects.org apply to the differences between a wiki as a tool and a wiki as an application. An application has been pre-built to do certain things for its target audience. This makes it "easier" to use (assuming those are the things you want to do). A tool can be grasped by its user and employed in many different ways as the user learns (and using tools is a learning experience).

All wikis have non-wiki-like elements mixed into them, much as some dishes are composed of a main ingredient that has other ingredients added to modify its strong taste. The strongest examples are probably those having to do with identifiying users and with protecting the content of wiki pages. Other examples might be page or content classifications schemes that give the wiki's pages a hierarchical organization. These non-wiki elements crosscut the wiki elements rather than becoming incorporated into them. Like cooking, the balance of the proportions and the effectiveness of the elements chosen to mix in have a great deal to do with whether the wiki contributors find the  resulting wiki tasty.

Wikis can also be approached as a set of games. Much like a deck of playing cards, wikis can be used to play different families of games, each with its own rules, expectations and results.

Wikis can be thought about as a strategy. Organizations can use wikis as safe and sensitive areas for innovation to take root. Wikis can be used as development tools that allow organizations to post-pone development decisions until the decisions are really necessary. Development in a wiki environment feeds back into an organization's culture and encourages communication and development of responsibility across organizational roles

A major wiki strategy is  neutrality: always try to avoid doing things that will force future decisions in certain directions. In many cases what look like necessary decisions can be avoided. When decisions are made make only as many as necessary and beware of decisions that seem to "follow" after certain others...they may be customary, but not necessary. When possible make decisions that can be reversed or undone. Limit the scope of decisions to the minimum scope necessary. There is always a temptation to extend decisions into areas that did not call for them and where they are not immediately needed. Try to make decisions that do not depend on larger frameworks of mechanisms of organizational power to be effective (in programming this is called coupling)

]You can also think of a wiki as a system. Like all systems wiki's have a boundary that separates them from other things and events have to cross that boundary to affect the wiki. Some systems have a high threshold that keeps them from being changed unless a lot of energy is applied to them. Wikis belong to the family of systems that have a very low threshold, so that change in their environment can easily affect the wiki. Another system with a very low threshold would be email: you get and idea, you fire off an email to someone. Systems also have upper levels of how much input they can accept. In the case of email the upper boundary is not very high. As the amount of energy you are trying to deal with grows you need more resource that sending emails with attachments provides. Because they have such a simple and extensible inner structure, a wiki's upper boundary for adsorbing energy from its environment is very high.

As systems wikis are self de-organizing.  A wiki is a simple construct that has no "organs", no complex internal subsystems that must be intergrated into its operations. Information can be put into a wiki on a page by page basis, without the need to all the pages to be part of an "organized" whole. Most information suffers from too much organization rather than too little. the wiki allows for spaces to be opened up around the elements of information which can be usefully explored once the information has be de-organized by putting it into the wiki context.

In the same sense working in the wiki context is de-individuating. The work itself can come to the foreground and the questions of identity, authorship and ownership of information can go to the background in a wiki environment.

A wiki tends toward being bare bones. In accordance with one of Ward's origional goals when creating the first wiki, a wiki wants to show not only the results of people's work, but the tools by which they did the work. This "showing" of how the work was done means that the work products will let their "bones" show through and not be as polished and sealed off from inspection as the results of more commercial development.

As a system a wiki has positive side-effects on the other systems in a business or organization that it interacts with: The availablity of the wiki tends to increase autonomy, innovation and individual responsibility in other systems.

You can also think of a wiki as a conversation, a conversation between its contributors and the server in the background that executes their wishes. Thinking about the file system illustrates the difference between the wiki and other interlocutors that are not as intelligent. The file system stores what you put in it. It offers search facilities, and may even be capable of automated backups and cross system file sharing. The wiki, on the other hands, takes creative action on your behalf. In the simplest sense this involves turning certain things you write into links. At one level further down it takes what appears to the contributor as a document (which is edited on the wiki) and turns it into a record in a database or a file on disk.

Thinking about wikis takes place against a general theory about how work happens. One possibility that starts to emerge is that most work is unconscious, people do what they do, but they don't know what they do. Work raises into consciousness for a variety of reasons and one thing about mediums like wiki's that have a low threshold of response is that they might be used to "map" or "catch" such opportunities for learning, change and innovation--a sort of work "radar" where the blips of "consiousness" register and can be further explored.


I (Ron Murch) came across an interesting article that got me thinking about the relationships between wiki technologies and personal knowledge management.  In exploring and refining theories of, or related to, wikis, one important aspect will be to create the links and relationships with other theory bases and referent disciplines.  Text, as referred to above may be the starting point for wikis, but as other forms of content emerge in digital form (photographs, sound, video, perhaps haptic devices, etc.), the theories behind wikis should be sufficiently robust to accommodate these additional mechanisms.